QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930294.txt

Internet Message Format | 1994-06-04 | 12KB

Date: Fri, 12 Nov 93 04:30:02 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #294
To: tcp-group-digest


TCP-Group Digest            Fri, 12 Nov 93       Volume 93 : Issue  294

Today's Topics:
              FTP client on SysV TLI (was: NOS FTP Bug)
                      KA9Q NET problem once more
                        On the merits of KISS
                       Re- TCP broadcast storm
                        Three things (3 msgs)
                    WinQVT/Net ( was Campus Net )

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 12 Nov 1993 10:16:34 +0200 (EET)
From: [e-mail] ("Matti E. Aarnio [OH1MQK]")
Subject: FTP client on SysV TLI (was: NOS FTP Bug)
To: [e-mail] (Steve Sampson)

> [e-mail] says:
> >In one sense, it's a good idea to be conservative what you send in order
> >to avoid breaking existing software.  Yet progress must be made; at some
> >point you have to make changes - and these changes might expose
> >previously-unknown-to-be-broken software.
> > - Brian

  I should check what exactly has been going on, but these things sound
very much like my experiences with  NIC.FUNET.FI, if you know the machine :)

> While I agree that new NOS routines can't be responsible for working with
> AT&T machines, maybe we can at least make NOS work per the RFC, and then any
> problems with AT&T users can be answered with "tough tits, get yourself
> something that works".  :-)
>
> By the way, the Sun machine at ds.internic.net also sends out 220- on every
> line just like NOS, so maybe this is the way everyone is interpreting the RFC??

  As a startup banner, they throw at you a screenfull of 220 replies, and
it happens in accordance with FTP's protocol specs:
 nnn-    starts multiline response
  more multiline response lines
 nnn     ends multiline response

Now I know that several older programs (including BSD ftp-client) made
assumption that there won't be more than some small number of those lines.
Usually at most 4 lines..  Such assumption is, of course, wrong.

> P.S.  Anyone who has the BSD ftp and ftpd ported to the 3B2 and SysV 3.2,
> I wouldn't mind a copy.  Just the thought of all the changes to the
> include files makes me tired :-)

  If somebody ports the DNS resolver to TLI, that helps a LOT!
I might do it eventually too, but I have so many other more urgent
things to do (well, which directly affect my activities..)

> ---
> Steve, N5OWK

 /Matti Aarnio <[e-mail]> OH1MQK

------------------------------

Date: Thu, 11 Nov 1993 07:32:26 -0600
From: [e-mail] (Steve Jones)
Subject: KA9Q NET problem once more
To: [e-mail], [e-mail]

I noticed that behavor whenever I got REAL short on memory.  I went to OS/2
to get a bigger dos box
Steve
[e-mail]
[e-mail]

------------------------------

Date: Thu, 11 Nov 1993 15:18:53 -0600 (CST)
From: Steve Sampson <[e-mail]>
Subject: On the merits of KISS
To: [e-mail]

[e-mail] writes:
>I've been thinking for some time that a new ROM for TNCs which does SLIP
>instead of KISS might be in order.

When I started playing with the X-1 TheNet this thought also crossed my mind.
The basis of KISS is that it adds a command byte to SLIP and can then be used
to modify TNC parameters.  But since the same parameters can be adjusted
through connection to the X-1, the command byte of KISS becomes redundant.
Thus even KISS is not needed, as SLIP would be good enough.

>but on the serial port it would look like a SLIP Point-to-Point connection

I agree.  This would really be neat.  Instead of the KISS code in the TNC
(module) a better routine would be an AX.25<->SLIP routine.  Since the X-1
has ARP, it would seem that it would be useful to just strip the AX.25 layer
and perform SLIP.  Same for the SLIP to AX.25 module which would convert the
IP address to the TNC callsign.  The advantage as I see it, is that you no
longer need the AX.25 code in NOS, but the disadvantage is that the TNC code
becomes so large that even 512k ROM is too small.  The Gracilis boards perform
this very well I understand, but they would have to be rated as something more
than a TNC.  Actually my idea of a good TNC would be the X-1 code minus the
Net/Rom stuff.  In this case all you have is a "dumb" router, but that's all
you need.  So given choices I would say see if you can get by with modifying
X-1 by deleting KISS, do that, or second just throwing out the Net/Rom part
if it comes to that.  (that stuff is too slow anyway).
---
Steve

------------------------------

Date: Thu, 11 Nov 1993 08:33:22 -0800
From: [e-mail] (Bob Braden)
Subject: Re- TCP broadcast storm
To: [e-mail], [e-mail]

  *> From [e-mail] Wed Nov 10 21:17:57 1993
  *> Date: Wed, 10 Nov 93 21:17:02 -0800
  *> From: [e-mail] (Phil Karn)
  *> To: [e-mail]
  *> Cc: [e-mail], [e-mail], [e-mail],
  *>         [e-mail]
  *> In-Reply-To: Jon Postel's message of Mon, 8 Nov 1993 08:43:10 -0800 <[e-mail]>
  *> Subject: Re- TCP broadcast storm
  *> Content-Length: 553
  *> X-Lines: 11
  *>
  *> This confusion between the Internet itself and the hosts attached to
  *> it continues. Last week, during the Houston IETF, the New York Times
  *> carried an article titled "Traffic Jams on the Information Highway"
  *> (or words to that effect, this is from memory). The article was
  *> clearly about the extreme loads that certain popular *server machines*
  *> on the net have been experiencing, but the title metaphor obviously
  *> gives the (mis)impression that the NSF backbone communication links are
  *> overloaded. As far as I have been able to observe, they are not.
  *>
  *> Phil
  *>
  *>

Phil,

Yeah, that was noted by a number of people.  Dave Sincoskie (you know
him, I suspect!) twigged John Markoff personally about it, and John
said essentially that yes, he understood the distinction, but as a user
he did not care.  The main point of the article was the need to charge
for services, and I guess he thought the issue of host/net services
was secondary.

Bob

------------------------------

Date: Fri Nov 12 14:22:52 1993
From: [e-mail]
Subject: Three things
To: [e-mail]

1. G8BPQ does indeed include a packet driver that provides an AX.25 packetdriver
interface but not the SLIP/ETHER ones most software needs.
2. A SLIP TNC is overkill. Far more effective would be a DOS packetdriver akin
to etherslip but doing etherax25 conversions. This would entail squashing
ax.25 calls to 6 byte addresses (code is in the sun ax.25 driver already)
and prepending AX.25 headers and LAPB UI followed by a protocol byte of either
IP or ARP. For someone with reasonable PC assembler skills (not me!) I can't
see this being a horrific job.

The final result would let you run stuff like QVTNET over radio transparently
- and NCSA telnet, Waterloo FTP etc.

3. Is there a summary of differences between ccitt LAPB and the AX.25 LAPB
anywhere - or would someone be prepared to email me a list. I've got a very
nice compact implementation of LAPB I'm playing with, and turning it into
an AX.25 stack would be quite useful. [I know about the AX.25 headers etc
I'm interested in state machine differences and things like pthresh which
don't seem to be in ccitt LAPB.

Alan
GW4PTS@GB7SWN//[e-mail]

------------------------------

Date: Thu, 11 Nov 93 11:22:09 -0800
From: [e-mail] (John D. Hays)
Subject: Three things
To: [e-mail]

Alan,

Your argument (which follows) pre-supposes that everybody who runs AX.25 uses a
PC with DOS ... There are many other systems out there besides DOS, many of
which have a SLIP feature already available to their TCP/IP stack [for example
in my home network I have DOS, Windows, Domain/OS, NEXTSTEP, and hopefully
LINUX before long --- all of which have slip capable programs, a SLIP TNC
should allow any of these machines to go directly on to the AX.25 network
without modifying system code].  A SLIP TNC would provide a simple way to
connect any SLIP capable machine's IP stack to communicate on the AX.25
encapsulated IP network.

John KD7UW

Begin forwarded message:

From: [e-mail]
Via: uk.ac.swansea.pyramid; Thu, 11 Nov 1993 16:24:56 +0000
Date: Fri Nov 12 14:22:52 1993
Subject: Three things


2. A SLIP TNC is overkill. Far more effective would be a DOS packetdriver akin
to etherslip but doing etherax25 conversions. This would entail squashing

ax.25 calls to 6 byte addresses (code is in the sun ax.25 driver already)
and prepending AX.25 headers and LAPB UI followed by a protocol byte of either
IP or ARP. For someone with reasonable PC assembler skills (not me!) I can't
see this being a horrific job.

The final result would let you run stuff like QVTNET over radio transparently
- and NCSA telnet, Waterloo FTP etc.

Alan
GW4PTS@GB7SWN//[e-mail]

------------------------------

Date: Fri, 12 Nov 93 06:34:01 GMT
From: [e-mail] (Ron Atkinson  N8FOW)
Subject: Three things
To: [e-mail]

     What about the backoff timers that are in NOS that aren't in various
other TCP/IP programs? I too would like to run WinQVT, Linux, etc... over
packet, but it's not designed for packet radio environment.  That's part
of the reason why people are putting NOS systems between their tnc's and
their other TCP/IP programs.
     Kinda curious,  how does the AX.25 stuff for the Sun work? Does it
work effectively in a heavily shared frequency like most major cities
have to deal with? I know the way that pings are done in most Unix systems
make it not very usable for packet and it seems to just key the transmitter
for long periods of time.
     I'm currently running NOS in MS Windows (yuck, but it works) and I
sometimes run 2 versions of NOS. Is there a way for them to talk to each other
or for something like  WinQVT to talk to NOS internally? This might be a quick
way to put something other than NOS on the air for the UI but let something
designed to operate in packet handle the tnc's, and on the same computer too.

Ron

------------------------------

Date: Thu, 11 Nov 1993 09:52:27 -0600
From: [e-mail] (Milton Miller)
Subject: WinQVT/Net ( was Campus Net )
To: [e-mail], [e-mail]

John D. Hays <[e-mail]> wrote:
> I've been thinking for some time that a new ROM for TNCs which does SLIP
> instead of KISS might be in order.  There would probably need to be a loader
> program of some type that downloaded Callsign, PARAMs, etc.  to the TNC, but on
> the serial port it would look like a SLIP Point-to-Point connection ... Then
> various implementations of TCP/IP which speak SLIP could access the AX.25
> encapsulated IP network....


Does TheNet X1H have this capability?

milton

------------------------------

End of TCP-Group Digest V93 #294
******************************
******************************